In client-server computer systems, clients rely on servers to provide needed services. In such systems, server response time can vary due to workload at the server. In some cases, a server's speed of response to a particular request is not fixed or deterministic and is dictated by the processing needed to respond to the request, communications that need to be performed in order to respond to the request, and the backlog or queue of requests on the server. For example, an authentication, authorization, and accounting (AAA) server may need to request user information from an Lightweight Directory Access Protocol (LDAP) server in order to process a Remote Authentication Dial-In User Service (RADIUS) Access Request.
Given the variable time needed for a server to satisfy a request and the fact that a server may also crash or otherwise be unable to respond to a request from a client, many clients are implemented with timeout mechanisms. A “timeout mechanism” allows the client to wait an appropriate amount of time before resending a request, sending the request to another server, or any other appropriate action to take based on the assumption that the server will not send a timely response.
One approach for implementing a timeout mechanism, the fixed timeout approach, is to use a fixed timeout on the client. In the fixed timeout approach, a client sends a request, and if a response to the request does not come within a predefined period of time, then the client “times out”. After timing out, the client will either resend the request to the same server or will send the request to another server (“failover” to another server).
In the fixed timeout approach, given a particular request, the client will wait time T for a response from the server and will retry the request R times, again waiting time T for each retry. In a situation where the server cannot respond in time T to the request, either because the server is down (has failed), or the processing of the request has taken too long, then the client waits for a total time of R*T without a response to the request and then fails over to another server. In some approaches, the time T varies with the number of times the request has been resent. In Dynamic Host Configuration Protocol (DHCP), for example, the timeout values increase logarithmically with the number of retries performed.
A problem with the timeout approach is that the client wastes the total time to failover of R*T. Another problem with the timeout approach is that failover time is constant or predefined for a particular client. Consider, for example, a client C that sends a request to a server S. The client has a fixed timeout of T seconds configured. In the case where the server takes T+1 seconds to respond to the request, the client will timeout after T seconds and resend the message to the server S. This wastes time on the client, since it will retry the request R times, taking a total of R*T seconds before failing over to another server. It also wastes R*(T+1) seconds on the server which receives R requests and spends T+1 seconds on each request. Ideally, the client would only send one request and would wait for the response that comes at T+1 seconds. Then, the server would only have to process one request.
Therefore, there is clearly a need for a system that enables clients to wait an appropriate amount of time for responses to requests sent to servers.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.